Packet filtering rules that match on packet's header fields can be used to implement a firewall policy to determine which packets should be admitted and which should be dropped. For stateful firewall rules, a record has to be kept of at least the admitted packets in order to correlate the subsequent packets to determine whether the packets belong to a previously established connection. The record can then be used, for example, to admit reply direction packets for the connections where forward direction packets were admitted.
This “connection tracking” may be further enhanced by tracking related connections even when the Internet protocol (IP) addresses and/or port numbers of the related data connection may be different from the original control connection. For instance, the data connections related to file transfer protocol (FTP) control connections can be used with the premise that if the control connection was admitted, then the data connections should be admitted too, As a further refinement, the connection tracking state may be used to keep track of network address and/or port translation (NAT/NAPT), allowing reply direction packets to be properly correlated with the original connection and reverse transformation to be performed. This is essential in allowing the source of the connection to remain unaware of any packet header transformations.
There are several practical problems in implementing a stateful firewall with the connection tracking facility. First, packets such as reply packets are admitted on the basis of a valid connection tracking entry under a particular firewall policy. If the firewall policy changes, then the validity of each connection tracking entry must be assessed or “revalidated” under the new policy. Failure to do so may result in wrongfully admitting packets. Revalidation may be performed by iterating through all connection tracking entries after each such policy change and removing the connection tracking entries for the connections that have become stale.
This solution has a few problems, though. Such revalidation may take a lot of time and resources if there are thousands of connection tracking entries and if policy changes are frequent. Additionally, such a revalidation may require the presence of the full packet headers and metadata (e.g., tunneling headers) of the original packet to properly run the original packet through the packet processing pipeline and the firewall rules to determine if the connection would still be admitted. These concerns have been roadblocks for implementing this strategy in practice.
Second, if the existing connection state is not to be implicitly trusted for admitting return or related traffic, the firewall rules have to be duplicated for each packet direction to be able to match the reply direction packet headers against the firewall rules. This duplicates the resource use for the rules in both the control and data planes.
Also, in some cases the reply direction packets may have headers that are not simply reversed from the original direction packet, as is the case when an Internet control message protocol (ICMP) response is sent to a user datagram protocol (UDP) packet, or when an ICMP Echo response is sent for an ICMP echo request. This further complicates creation of the firewall filter rules by the control plane, and increases the resource use on the control and data planes in the form of additional packet filtering rules
Third, as related connections may have practically arbitrary packet headers in relation to the original master connection, it is not possible to write firewall rules in terms of the actual packet headers that would admit or deny the related packets without basing this decision on the state of the connection tracking entry (e.g., related or established). This would make any firewall policy changes ineffective in changing the treatment of the related connection packets. For instance, an FTP data download may be allowed to continue even after a firewall policy change shutting down the FTP control connection.